Hierarchical Service Oriented Application Topology Generation for a Network

ABSTRACT

The technology disclosed relates to understanding traffic patterns in a network with a multitude of processes running on numerous hosts. In particular, it relates to using at least one of rule based classifiers and machine learning based classifiers for clustering processes running on numerous hosts into local services and clustering the local services running on multiple hosts into service clusters, using the service clusters to aggregate communications among the processes running on the hosts and generating a graphic of communication patterns among the service clusters with available drill-down into details of communication links. It also relates to using predetermined command parameters to create service rules and machine learning based classifiers that identify host-specific services. In one implementation, user feedback is used to create new service rules or classifiers and/or modify existing service rules or classifiers so as to improve accuracy of the identification of the host-specific services.

RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.16/261,134, entitled “HIERARCHICAL SERVICE ORIENTED APPLICATION TOPOLOGYGENERATION FOR A NETWORK”, filed on Jan. 29, 2020 (Attorney Docket No.LBND 1002-4), which is a continuation of U.S. application Ser. No.15/919,064, entitled “HIERARCHICAL SERVICE ORIENTED APPLICATION TOPOLOGYGENERATION FOR A NETWORK”, filed on Mar. 12, 2018 (Attorney Docket No.LBND 1002-3), which is a continuation of U.S. application Ser. No.14/878,910, entitled “HIERARCHICAL SERVICE ORIENTED APPLICATION TOPOLOGYGENERATION FOR A NETWORK”, filed Oct. 8, 2015 (Attorney Docket No. LBND1002-2), which claims the benefit of U.S. Provisional Application No.62/169,489, entitled “HIERARCHICAL SERVICE ORIENTED APPLICATION TOPOLOGYGENERATION FOR A NETWORK”, filed Jun. 1, 2015 (Attorney Docket No. LBND1002-1). The provisional and non-provisional applications are herebyincorporated by reference for all purposes.

INCORPORATIONS

Materials incorporated by reference in this filing include thefollowing:

“ORGANIZING NETWORK PERFORMANCE METRICS INTO HISTORICAL ANOMALYDEPENDENCY DATA,” U.S. Non. Prov. application Ser. No. 14/276,826, filedMay 13, 2014 (Attorney Docket No. LBND 1000-4); and

“ORGANIZING NETWORK PERFORMANCE METRICS INTO HISTORICAL ANOMALYDEPENDENCY DATA,” U.S. Non. Prov. application Ser. No. 14/276,846, filedMay 13, 2014 (Attorney Docket No. LBND 1000-5).

BACKGROUND

The subject matter discussed in the background section should not beassumed to be prior art merely as a result of its mention in thebackground section. Similarly, a problem mentioned in the backgroundsection or associated with the subject matter of the background sectionshould not be assumed to have been previously recognized in the priorart. The subject matter in the background section merely representsdifferent approaches, which in and of themselves may also correspond toimplementations of the claimed technology.

The advent of cloud computing and on-line services has led toexponential growth in size and complexity of data centers. This hascreated unprecedented challenges for system management and monitoring.Given the scale and scope of such large data centers, network operatorsand monitoring tools are overwhelmed with monitoring and analyticsmetrics across several thousand network layers and network elements.Currently, network operators and monitoring tools conduct much of theforensic examination based on communications between numerous hosts of anetwork. Such a host-based network analysis creates a cloud picture ofthe network health with numerous noise channels that can be obviated.

It is therefore necessary to provide methods and systems that enhancethe transparency and feasibility of the network monitoring and analyticsmetrics by adapting a service-centric model of network analysis. Anopportunity arises to increase operator-friendliness in networkmonitoring environments. Improved user experience and engagement andhigher customer satisfaction and retention may result.

SUMMARY

The technology disclosed relates to understanding traffic patterns in anetwork with a multitude of processes running on numerous hosts. Inparticular, it relates to clustering processes running on numerous hostsinto local services and clustering the local services running onmultiple hosts into service clusters, using the service clusters toaggregate communications among the processes running on the hosts andgenerating a graphic of communication patterns among the serviceclusters with available drill-down into details of communication linksin the communication pattern graphic. It also relates to usingpredetermined command parameters to create process rules that identifyhost-specific processes. In one implementation, user feedback is used tocreate new process rules and/or modify existing process rules so as toimprove accuracy of the identification of the host-specific processes.

Other aspects and advantages of the present invention can be seen onreview of the drawings, the detailed description and the claims, whichfollow.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, like reference characters generally refer to like partsthroughout the different views. Also, the drawings are not necessarilyto scale, with an emphasis instead generally being placed uponillustrating the principles of the technology disclosed. In thefollowing description, various implementations of the technologydisclosed are described with reference to the following drawings, inwhich:

FIG. 1 shows an example environment of generating a hierarchical serviceoriented application topology for a network.

FIG. 2 shows one implementation of identifying hosts of a network withcommon functionality.

FIG. 3 shows one implementation of classification of hosts with commonfunctionality into service profiles.

FIG. 4 illustrates a workflow of generating hierarchical serviceoriented application topology for a network.

FIG. 5 depicts one implementation of a communication patterns graphicthat graphically represents a host oriented network topology.

FIGS. 6A and 6B illustrate implementations of communication patternsgraphics that graphically represent a service oriented applicationtopology.

FIG. 7 is a flowchart showing a method of understanding traffic patternsin a network with a multitude of processes running on numerous hosts.

FIG. 8 is a block diagram of an example computer system forunderstanding traffic patterns in a network with a multitude ofprocesses running on numerous hosts.

DESCRIPTION Introduction

Implementations of the technology disclosed can include one or more ofthe following features and/or features described in connection withadditional implementations disclosed. In the interest of conciseness,the combinations of features disclosed in this application are notindividually enumerated and are not repeated with each base set offeatures. The reader will understand how features identified can readilybe combined with sets of base features identified as implementationssuch as service oriented application topology generation environment,vector space model representation, process similarity determination,process and host clustering, host classification, rule basedclassification, disjoint process generation, or communication patternsgraphic.

As the scale and complexity of a network grows, the number of hosts,processes, services and other network entities that require monitoringalso increase. As a result, the task of identifying root causes ofanomalies in the network and mitigating them becomes unmanageable. Thetechnology disclosed solves this technical problem by generating aservice oriented communication model that clusters the hosts in thenetwork into services. In network architecture, the number of hosts isusually a multiple of the number of services in the network. Forexample, a storage service can include as hosts hundreds of server racksor thousands of individual servers. In addition, a service in a networkcan comprise of applications, processes, switches, routers, loadbalancers, and other network entities. Therefore, creating a networktopology based on hosts or other network resources creates a noisyrepresentation of the network architecture, which is cumbersome for anetwork operator to evaluate and work with.

The service oriented communication model is particularly distinct fromthe traditional host based network models that require the operator toevaluate a large number of host relationships. The service orientedcommunication model generates for display communication patterns betweenservice clusters that can be further drilled-down to view mappingsbetween the hosts clustered in the service clusters.

Accordingly, the amount of information presented to the operator issubstantially streamlined, thereby providing the operator with a betterunderstanding of the overall network communications. Enhanced operatorfriendliness and faster diagnosis of anomalies may result.

The technology disclosed can be used for understanding traffic patternsin a network that includes a multitude of processes running on numeroushosts. The technology disclosed can be used in a variety of applicationsincluding, information technology (IT) systems, telecommunicationssystems, financial systems, security trading, banking, businessintelligence, marketing, mining, energy, etc. One implementation of thetechnology disclosed relates to IT systems operations. IT operationaldata refers to any data that is produced by any human, system (hardwareor software), machine, application, software, or component within an ITenvironment. Some examples of this operational data include metrics(server, network, database, services, hypervisor), alerts, logs, errors,software pushes, or application topology.

Examples of systems, apparatus and methods according to the disclosedimplementations are described in an information technology (IT) context.In other instances, the technology disclosed may be applied to frauddetection, telecommunications systems, financial systems, securitytrading, banking, business intelligence, marketing, mining, energy, etc.Other applications are possible, such that the following examples shouldnot be taken as definitive or limiting either in scope, context orsetting.

The technology disclosed can be implemented in the context of anycomputer-implemented system including an on-demand database system, amulti-tenant environment, or the like. Moreover, this technology can beimplemented using two or more separate and distinct computer-implementedsystems that cooperate and communicate with one another. This technologycan be implemented in numerous ways, including as a process, a method,an apparatus, a system, a device, a computer readable medium such as acomputer readable storage medium that stores computer readableinstructions or computer program code, or as a computer program productcomprising a computer usable medium having a computer readable programcode embodied therein.

As used herein, the “identification” of an item of information does notnecessarily require the direct specification of that item ofinformation. Information can be “identified” in a field by simplyreferring to the actual information through one or more layers ofindirection, or by identifying one or more items of differentinformation which are together sufficient to determine the actual itemof information. In addition, the term “specify” is used herein to meanthe same as “identify.”

As used herein, a given signal, event or value is “based on” apredecessor signal, event or value of the predecessor signal, event orvalue influenced by the given signal, event or value. If there is anintervening processing element, action or time period, the given signal,event or value can still be “based on” the predecessor signal, event orvalue. If the intervening processing element or action combines morethan one signal, event or value, the signal output of the processingelement or action is considered “based on” each of the signal, event orvalue inputs. If the given signal, event or value is the same as thepredecessor signal, event or value, this is merely a degenerate case inwhich the given signal, event or value is still considered to be “basedon” or “dependent on” the predecessor signal, event or value.“Responsiveness” of a given signal, event or value upon another signal,event or value is defined similarly.

Service Oriented Application Topology Generation

FIG. 1 shows an example environment 100 of generating a hierarchicalservice oriented application topology for a network. FIG. 1 includes anapplication data store 102, user feedback data store 105 and rulesdatabase 108. FIG. 1 also shows feature extraction engine 112, matchingengine 118, graphics engine 122, clustering engine 125, classificationengine 128 and network(s) 115. In other implementations, environment 100may not have the same elements or components as those listed aboveand/or may have other/different elements or components instead of, or inaddition to, those listed above, such as a rule induction engine,hierarchy data store, or application data assembly engine. The differentelements or components can be combined into single software modules andmultiple software modules can run on the same hardware.

Network(s) 115 is any network or combination of networks of devices thatcommunicate with one another. For example, network(s) 115 can be any oneor any combination of a LAN (local area network), WAN (wide areanetwork), telephone network (Public Switched Telephone Network (PSTN),Session Initiation Protocol (SIP), 3G, 4G LTE), wireless network,point-to-point network, star network, token ring network, hub network,WiMAX, WiFi, peer-to-peer connections like Bluetooth, Near FieldCommunication (NFC), Z-Wave, ZigBee, or other appropriate configurationof data networks, including the Internet. In other implementations,other networks can be used such as an intranet, an extranet, a virtualprivate network (VPN), a non-TCP/IP based network, any LAN or WAN or thelike.

In some implementations, the engines can be of varying types including aworkstation, server, computing cluster, blade server, server farm, orany other data processing system or computing device. The engine can becommunicably coupled to the databases via a different networkconnection. For example, feature extraction engine 112 and matchingengine 118 can be coupled via the network(s) 115 (e.g., the Internet),clustering engine 125 can be coupled via a direct network link andclassification engine 128 can be coupled by yet a different networkconnection.

In some implementations, data stores can store information from one ormore tenants into tables of a common database image to form an on-demanddatabase service (ODDS), which can be implemented in many ways, such asa multi-tenant database system (MTDS). A database image can include oneor more database objects. In other implementations, the databases can berelational database management systems (RDBMSs), object orienteddatabase management systems (OODBMSs), distributed file systems (DFS),no-schema database, or any other data storing systems or computingdevices.

Application data store 102 includes a list of applications, services andprocesses running on different hosts on a network, including routers,switches, firewalls, load balancers and servers. In one implementation,the list is maintained by the operating systems running on the hosts andis retrieved from the different hosts by an agent that carries out anapplication discovery process. In other implementations, applicationdata store 102 includes a list of local programs of the different hosts,including startup programs, which run immediately when the hosts bootup.

In some implementations, the list of applications in the applicationdata store 102 can be identified using various application attributessuch as process identifiers, authorized user identifiers, process names,command strings and listen ports. For example, the following commandstrings (C_(n)) identify four different processes running on differenthosts of a network. Examples of command strings include “su” commands,“bash” commands or other shell commands.

-   -   C_(A)=python web.py -c/etc/web.conf -x 1 -y 2    -   C_(B)=python app.py -c 10 -d -reload    -   C_(C)=python app.py -c 10 -d    -   C_(D)=/bin/mongod -c/etc/mongod.conf

Feature extraction engine 112 serves as a tokenizer or a parser thatparses each command string into segments. In another implementation, itserves as a shingle module that parses each of the segments of thecommand string into N grams of various lengths (unigrams, bigrams,trigrams), or sliding windows of N grams, or minimum and maximum grams.The following example shows one implementation of generating tokenshingles from a command string “python, app.py, -alpha, 1, -d, 2, -e,3.” In this example, the command string is first split at eachoccurrence of a space to construct word tokens, generating the sequence{python, app.py, -alpha, 1, -d, 2, -e, 3}. Following this, the sequenceof word tokens can be further parsed into sliding windows of fourcharacters. The resulting token shingles are {pyth, ytho, thon, app.,pp.p, p.py, -alp, alph, lpha, 1, d, 2, e, 3}.

Once the token shingles are constructed, the feature extraction engine112 filters the token shingles by calculating a term frequency-inversedocument frequency (TF-IDF) for each the token shingles, according toone implementation. In other implementations, different featureextraction or feature selection techniques can be used instead ofTF-IDF, including bag of words and indicator variables. A TF-IDFweighting, or score, forms a statistical measure that can be used toevaluate how important a word is to a command string. The importance isdeemed to increase linearly according to the number of times a wordappears in the command string, but is offset by how common the word isin all of the command strings in a body of command strings, or a list ofprocesses.

Various formulae can be used to compute a TF-IDF. In one example, theterm frequency (TF) can be the number of times the term appears in acommand string divided by the total number of terms in the commandstring. If a command string contains 1000 total terms and a term appears5 times, then the term frequency of the term in the command string is0.005 (5/1000). In this example, the document frequency (DF) can becomputed as the number of command strings that contain the term dividedby the total number of command strings in the list of processes. If theterm appears in 1,000 command strings out of a total of 10,000,000 thenthe document frequency (DF) is 0.0001 (1000/10000000) and the InverseDocument Frequency (IDF) is 10,000. The TF-IDF score is then calculatedby dividing the term frequency by the document frequency (TF/DF) ormultiplying the term frequency by the Inverse Document Frequency (i.e.,TF*IDF).

In the example described above, the TF-IDF score for the process listwould be 50 (0.005/0.0001 or 0.0005*10,000). In some implementations, ahigh TF-IDF score can result from a high term frequency (in the givencommand string) and/or a low document frequency of the term in the wholecollection of command strings; whereby the weights tend to filter outcommon terms. In other examples, other formulae can be employed tocalculate the TF-IDF score.

Also, a commonly used TF-IDF formula uses the natural logarithm of theInverse Document Frequency (Ln (IDF)). In this case, for a termappearing in all documents, Ln (1)=0. If a term appears only in 1command string among 10,000,000, then Ln (10,000,000)=16.

A high weight in TF-IDF can be achieved by a high term frequency in thegiven document and a low document frequency of the term in the wholecollection of documents; the weights hence tend to filter out commonterms.

In some implementations, certain junk command strings or junk tokenshingles are detected and filtered out before feature extraction orfeature selection. In one implementation, junk command strings or junktoken shingles are pre-specified. For example, token shingles that arekey value pairs can be automatically considered to be junk and deleted.In another example, command strings representing certain processes suchas print queues, fax queues or other administrative processes that arenot user-service oriented (e.g. virtual network computing) can beautomatically considered to be junk and deleted. In yet another example,command strings comprising certain regular expressions can be filteredout prior to further processing. In other implementations, automaticfiltering of junk command strings and/or junk token shingles can be usedin combination with the feature extraction.

In one implementation, TF-IDF is used to represent each filtered tokenshingle in the vector space based on the following counting function:

${t{f\left( {t,C} \right)}} = {\sum\limits_{x \in d}{f{r\left( {x,t} \right)}}}$

where fr(x, t) is defined as:

$f{r\left( {x,t} \right)}\begin{matrix}{= \left\{ {1,{{{if}\mspace{14mu} x} = t}} \right.} \\{\left\{ {0,{otherwise}} \right.}\end{matrix}$

The counting function tf(t,C) returns how many times the token shingle tis present in the command string C. In one example, for command stringC_(D)=/bin/mongod -c/etc/mongod.conf, tf(“mongod”,C_(D))=2 since thereare only two occurrences of the term “mongod” in command string C_(D).

Further, a command string vector is created using the following formula:

vC _(n)=(tf(t ₁ ,C _(n)),tf(t ₂ ,C _(n)),tf(t ₃ ,C _(n)), . . . tf(t_(n) ,C _(n)))

In addition, each dimension of the command string vector is representedby a token shingle. In one implementation, the resulting command stringvectors for command strings C_(A), C_(B), C_(C) and C_(D) can be asfollows:

-   -   vC_(A)=(0, 2, 2, 2)    -   vC_(B)=(0, 4, 2, 0)    -   vC_(C)=(2, 0, 2, 0)    -   vC_(D)=(4, 0, 4, 0)

In yet other implementation, different feature extraction or featureselection techniques can be used in addition or instead of to TF-IDF,including but not limited to, log (tf), wherein “tf” refers to termfrequency, tf/max (tf), log [tf/max (tf)], entropy, global frequency(GF), and total document IDF weighted global frequency (GFIDF).

Graphics engine 122 generates for display animated and interactivevisual representations of information generated, exchanged, stored orextracted in the service oriented application topology generationenvironment 100. In one implementation, visual representations generatedby the graphics engine 122 include graphic elements that are linked tothe hosts, processes and services in the network 115. These visualrepresentations are used to generate a graphic of communication patternsamong the services in the network 115. In another implementation, thegraphics engine 122 allows for drill-down into details of communicationlinks in a communication pattern graphic. The details identify the hoststhat are part of the drilled-down service along with processes runningon the hosts, according to yet another implementation.

Process Similarity Determination

The command string vectors are evaluated to determine whether theprocesses that they represent are similar. In some implementations, aplurality of techniques can be used to measure the process similarity.One example of such a technique is unigram overlap. The baseline unigramapproach considers two command string vectors to be correlated if theyhave higher Jaccard similarity than a threshold after unigrams areextracted from each process being represented and the Jaccard similarityis computed. The Jaccard coefficient between the unigrams of each pairof processes A and B is used to measure the similarity of the pair ofmessages.

${jaccard}{\left( {A,B} \right) = {\frac{\left| {A\bigcap B} \right|}{\left| {A\bigcup B} \right|} \leq \frac{{\min {A}},{\bigcap{B}}}{{\max {A}},{\bigcup{B}}}}}$

In some implementations, Jaccard similarity between two command stringscan be conditional upon the presence of certain essential tokenshingles.

In another implementation, an edit distance technique can be used todetermine the similarity between command string vectors representingdifferent processes. The edit distance between two command strings isconsidered, that is, two command strings are correlated if the number ofedits to transform one command string into the other is less than somethreshold value. In some implementations, a Levenshtein distance can beused as a metric for measuring the amount of difference between twocommand strings. The distance is the minimum number of edits required inorder to transform one command string into the other.

Cosine similarity is a vector-based similarity measure between commandstrings where the input command strings are translated to vectors in ahigh-dimensional space. Thus, more resembling command strings are alsocloser to each other in the vector space. In one implementation, thetransformation of the input command strings to vectors is done based onthe token shingles that appear in the command string, with each tokencorresponding to a dimension and the frequency of the token shingles inthe input being the weight of the vector in that dimension. The commandstring similarity is then given by the cosine similarity of the twovectors (i.e., the cosine of the angle between the two vectors).

Another similarity metric is Euclidean distance which is the length ofthe line segment connecting two command string vectors (two processes inthis context). The smaller the Euclidean distance between two processes,the more similar they are. The distance between vectors X and Y isdefined as follows:

${d\left( {x,y} \right)} = \sqrt{\overset{n}{\sum\limits_{i}}\left( {x_{i} - y_{i}} \right)^{2}}$

Therefore, Euclidean distance is the square root of the sum of squareddifferences between corresponding elements of the two command stringvectors.

FIG. 2 shows one implementation of identifying hosts of a network withcommon functionality. In particular, applying the formula above, theEuclidean similarities (CE_(XY)) 200 between the command string vectorsfor command strings C_(A), C_(B), C_(C) and C_(D) are determined to be:

-   -   CE_(AB)=2.828    -   CE_(AC)=3.464    -   CE_(AD)=5.292    -   CE_(BC)=4.472    -   CE_(BD)=6.000    -   CE_(CD)=2.822

In other implementations, different similarity measures can be used todetermine similarity between the processes such as Tanimoto coefficient,Dice coefficient, Hamming distance, Needleman-Wunch distance or SellersAlgorithm, Smith-Waterman distance, Gotoh Distance orSmith-Waterman-Gotoh distance, Block distance or L1 distance or Cityblock distance, Monge Elkan distance, Jaro distance metric Jaro Winkler,SoundEx distance metric, Matching Coefficient, Dice Coefficient, OverlapCoefficient, Variational distance, Hellinger distance or Bhattacharyyadistance, Information Radius (Jensen-Shannon divergence) Harmonic Mean,Skew divergence, Confusion Probability, Tau, Fellegi and Sunters (SFS)metric, FastA, BlastP, Maximal matches, q-gram, Ukkonen Algorithms andSoergel distance. In yet other implementations, different correlationmeasures can be used.

Process and Host Clustering

Given a similarity distance measure, a reasonable procedure forclustering n observations about the processes can be used by theclustering engine 125. First, the command string vectors are groupedinto as many clusters as there are observations, that is, with eachobservation forming a separate cluster. Following this, the pair ofobservations that are nearest one another are clustered, leaving n−1clusters. Next, a cluster is merged with a pair of clusters that arenearest to one another, leaving n−2 clusters. Continuing in this manner,the number of clusters are reduced by one at each action, until a singlecluster is formed consisting of all n observations. At each action, thedistances at which the clusters are formed are tracked.

In other implementations, clustering can include mapping each commandstring to a process signature. When two or more command strings map tothe same process signature, they are grouped in the same cluster. Inother implementations, different clustering approaches can be used,including hash-based approach where each observation is placed in acluster based on the value it produces based on some hash function,hierarchical agglomerative clustering with ward linkage criterion or ahierarchical divisive method that follows the reverse procedure in thatit begins with a single cluster consisting of all observations, formsnext 2, 3, etc. clusters, and ends with as many clusters as there areobservations.

The process clusters identify hosts which share common functionality. Inother words, hosts with processes that are clustered together aredetermined to have similar functionality.

In some implementations, the user feedback can be received on theclustered hosts and processes. The user feedback can be stored in theuser feedback data store 105. For example, an operator can choose toignore an entire process cluster or reject certain specific hosts and/orprocesses from a cluster. Subsequent clustering operations can take intoaccount such feedback and produce more user-desired results.

Host Classification

Once hosts that have similar processes are identified, clustered hostsare classified into service profiles using a machine learning basedclassifiers that use the token and shingles as features. A serviceprofile is a set of processes that forms a logical unit. In oneimplementation, each clustered host corresponds to a process signature,and is evaluated against a rule database 108 for classification to aparticular service profile. FIG. 3 shows one implementation ofclassification 300 of hosts with common functionality into serviceprofiles. The distance between the observations can be measured usingthe nearest neighbor or single linkage method. Observations C_(A) andC_(B) are nearest (most similar) and, as shown in FIG. 2, are grouped inthe same cluster 1 of FIG. 3. Similarly, observations C_(C) and C_(D)are nearest (most similar) and are grouped in the same cluster 2 of FIG.3.

In another optional implementation, the clustered hosts are labelled asservice profiles based on receiving manual labelling of hosts fromusers. For example, an operator can evaluate the processes running on ahost such as an application server and can use his or her experience toidentify the host as belonging to a particular type of service profilelike Mongo database service. In some implementations, the optionalmanual labelling is performed only when the machine learning basedclassification fails.

One example of machine learning is logistic regression in whichcross-validation is used to classify hosts into service profiles.According to this example, classification engine 128 classifies thehosts based upon a logistic regression algorithm. Classification engine128 applies the logistic regression algorithm to the binary commandstring vectors of the processes to compute the probability P of aclassification of the hosts which run those processes. In otherimplementations, the classification engine 128 receives feedback fromthe user in the form of manually labelled hosts and/or or any other typeof classification data from an external source, and generates updatedlogistic regression parameters. The user feedback can be stored in theuser feedback data store 105. Since the classification engine 128 useslogistic regression parameters that reflect external classificationdata, the accuracy of the host classification is significantly enhanced.

In other implementations, users can select a process cluster or a subsetof processes in the process cluster and further assign them a serviceprofile from a pre-selected list of profiles. In yet otherimplementations, the users can specify their own custom serviceprofiles.

In further implementations, the command string vectors are furtherfiltered using the above described TF-IDF prior to being logisticallyregressed. This also results in the enhanced accuracy of the hostclassification.

In yet other implementations, other supervised learning algorithms canbe used, including support vector machines (SVMs), neural nets, naïvebayes, memory-based learning, random forests, decision tress, baggedtrees, boosted trees and boosted stumps.

Rules Based Classification

Rules database 108 includes rules that are defined so as to classifyprocesses and services into service profiles. In one implementation,rules database 108 includes process-specific rules that are used by thematching engine 118 to evaluate filtered token shingles of a process andto determine whether they match a reference process defined by theprocess-specific rules. Once a positive determination is made, theevaluated process is identified to be the same as the reference process.In some implementations, process-specific rule based matching can beused to identify command strings that belong to the same process. Thisallows further filtering of similar processes before they are evaluatedto identify hosts with common functionality, as described above in thisapplication under the section entitled “Process SimilarityDetermination”.

In one implementation, the process-specific rules are defined based onkey command parameters such as interpreter, script name, program name,service port, options, mandatory parameters and available parameters.The command parameters can be automatically extracted using the featureextraction engine 112, as described above, and/or can be optionallyselected based on human feedback. In some implementations, the optionalhuman feedback based selection is performed only when the featureextraction engine 112 fails to identify the command parameters.

In one example, the command parameter values for command strings C_(A)and C_(D) are described below:

-   -   C_(A)=python web.py -c/etc/web.conf -x 1 -y 2        -   interpreter=python        -   script=web.py        -   options=[-x, 1, -y. 2]    -   C_(D)=/bin/mongod -c/etc/mongod.conf        -   interpreter=null        -   script=/bin/mongod        -   options=[-c, /etc/mongod.conf]

The following example shows one implementation of process-specific rulebased matching:

-   -   C_(B)=python app.py -c 10 -d -reload    -   C_(C)=python app.py -c 10 -d″    -   Process-specific rule X=[interpreter=python,        -   script_name=app.py,        -   mandatory_params={reload: True}]

According to the process-specific rule based matching above, commandstring C_(B) matches the process-specific rule X. In contrast, commandstring C_(C) does not match the process-specific rule X.

The following example shows another implementation of process-specificrule based matching:

-   -   C_(B)=python app.py -c 10 -d -reload    -   C_(C)=python app.py -c 10 -d″    -   Process-specific rule Y=[interpreter=python,        -   script_name=app.py,        -   optional_params={reload: True}]

According to the process-specific rule based matching above, commandstring C_(B) matches the process-specific rule Y. Similarly, commandstring C_(C) also matches the process-specific rule Y.

Along with process-specific rules, the rules database 108 also maintainsservice-specific rules that are used by the matching engine 118 toevaluate a set of command strings and to determine whether the setmatches a reference service profile defined by the service-specificrules. Once a positive determination is made, the evaluated set ofcommand strings is identified to be the same as the reference serviceprofile. The following syntax is one example of a service-specific rule:

-   -   Service-specific rule Z=[P_(A), P_(B), P_(C), . . . P_(N)]

According to one implementation of service-specific rule based matching,each process-specific rule specified by the service-specific rule shouldmatch against a different command string in the set of command stringsbeing evaluated by the matching engine 118. The matching can be of twotypes and can be applied independently or in combination. In oneimplementation, the matching includes identifying matching commandparameter values. In addition to the service-specific rule basedmatching, one or more certain essential command parameter valuesspecified by the service-specific rule must be present in the set ofprocess-specific rules being evaluated by the matching engine 118. Ifthe one or more certain essential command parameter values exist arepresent, the set of process-specific rules is determined to have theservice profile corresponding to the service-specific rule.

In some implementations, the users can create a new customer-specificservice rule by specifying a set of processes. The customer-specificservice rule can include weight coefficients that prioritize thesignificance of the processes in the set of processes based on customerfeedback, according to one implementation.

Disjoint Process Generation

In some implementations, the processes can be grouped into servicesusing a clustering algorithm that generates independent sets ofprocesses mapped to sets of hosts. The results of the clusteringalgorithm produce disjointed process clusters that are more suitable forfacilitating user feedback. The clustering algorithm further assists inidentifying independent sets of processes that are not classified asbelonging to a particular service profile. This in turn allows users toprovide feedback on a smaller set of processes with unique behavioralattributes.

According to one implementation, the clustering algorithm includes threeactions—feature selection (tokenization), item set clustering andindependent sets generation. Feature selection maps similar processesinto one group as described above in this application. As a result,processes with minor differences across hosts do not result infragmentation of clusters. In some implementations, feature selection isapplied to each command string of a host to extract relevant tokenshingles that form a process signature.

Following this, for each process signature, the sets of hosts runningthe process with the corresponding process signature are clustered, asdescribed in the section entitled “Process and Host Clustering”. Inaddition, filtering is performed to remove any irrelevant token shinglesand/or command strings.

Then, pairs of process signatures are combined by taking an intersectionof sets of hosts. The intersections results in sets of hosts that runsignature pairs. Further, the sets are repeatedly combined to constructlarger sets of process signatures until the set intersection is NULL.Some examples of process signatures based clusters are as follows:

-   -   (Agent)—{subset of hosts}    -   (Mongo)—{subset of hosts}    -   (OpenTSDB)—{subset of hosts}    -   (Agent, Mongo)—{subset of hosts}    -   (Agent, OpenTSDB)—{subset of hosts}    -   (Mongo, OpenTSDB)—{subset of hosts}    -   (Agent, Mongo, OpenTSDB)—{subset of hosts}

Advancing further, independent sets are generated from the processsignatures based clusters so as to produce service orientedclassification of hosts. Some examples of service orientedclassification of processes is given below:

-   -   (Agent Signature)—{subset of hosts}    -   (Mongo Signature, OpenTSDB Signature)—{subset of hosts}

In one implementation, the clustering algorithm that generatesindependent sets of processes mapped to sets of hosts can be defined asfollows:

-   -   Initial set S: A, B, C, D, . . .    -   Final solution T={ }    -   Pick A        -   Calculate A & B, A-B, B-A        -   Store B-A, A & B in S        -   A=A-B        -   Repeat with C, D . . .    -   A-B-C-D . . . is independent, store in T    -   Repeat with B, C, D . . .

where “A&B” refers to intersection of A and B, “A-B” identifies elementsthat are in A but not in B and “B-A” identifies elements that are in Bbut not in A.

What follows is an example of applying the independent sets algorithm tohost clusters that result in service oriented classification ofprocesses.

-   -   Assume processes P1, P2, P3, P4 run on host H1    -   Assume processes P1, P2, run on host H2    -   Assume processes P1, P3, P4 run on host H3

It is preferable to classify the processes as services. For instance, ifprocess P1 is a java process, then instead of referring to it as simplya java process, it can be specified as a HadoopDataNode, which requiresjava to be run in a particular way. If the processes are notappropriately classified, then the processes can be identified in a waythat allows the customers to easily provide their feedback about theprocesses. According to one implementation, this can be achieved byclustering the processes as follows:

-   -   P1->H1, H2, H3    -   P1, P2->H1, H2    -   P1, P3->H1, H3    -   P1, P4->H1, H3    -   P1, P2, P3, P4->H1

The above clustering output is produced using item set clustering. Whilesuch an output is useful, it is not most-suitable for receiving customerfeedback. In addition, if a process, such as process P1, occurs inmultiple clusters, then the customers may have to give the same feedbackmultiple times. Therefore, it is preferable that each of these processsets are disjointed as follows:

-   -   P1->H1, H2, H3    -   P2->H1, H2    -   P3→H1, H3    -   P4->H1, H3    -   P3, P4->H1, H3

First, the process sets of the item set clusters are classified intorespective sets of A, B, C, D and E.

A={P1},B={P1,P2},C={P1,P3},D={P1,P4},E={P1,P2,P3,P4}

Then, mutually exclusive and collectively exhaustive disjoint sets X, Y,Z are determined for sets A and B.

-   -   X=A&B={P1}    -   Y=A-B=NULL    -   Z=B-A={P2}

Now, sets A and B are respectively replaced by disjoint sets X and Z.

-   -   X, Z, C, D, E

Then, mutually exclusive and collectively exhaustive disjoint sets X1,Y1, Z1 are determined for sets X and C.

X, C X={P1}, C={P1, P3}

-   -   X1=X & C={P/v}    -   Y1=X-C=NULL    -   Z1=C-X={P3}

Now, sets X and C are respectively replaced by disjoint sets X1 and Z1.

-   -   X1, Z, Z1, D, E

Then, mutually exclusive and collectively exhaustive disjoint sets X2,Y2, Z2 are determined for sets X1 and D.

X1, D X1={P1}, D={P1, P4}

-   -   X2=X1 & D={P1}    -   Y2=X1-D=NULL    -   Z2=D-X1={P4}

Now, sets X1 and D are respectively replaced by disjoint sets X2 and Z2.

-   -   X2, Z, Z1, Z2, E

Then, mutually exclusive and collectively exhaustive disjoint sets X3,Y3, Z3 are determined for sets X2 and E.

X2, E X2={P1}, E={P1, P2, P3, P4}

-   -   X3=X2 & E={P1}    -   Y3=X2-E=NULL    -   Z3=E-X2={P2, P3, P4}

Now, sets X2 and E are respectively replaced by disjoint sets X3 and Z3.

-   -   X3, Z, Z1, Z2, Z3

Then, mutually exclusive and collectively exhaustive disjoint sets I, J,K are determined for sets Z and Z1.

Z, Z1 Z={P2}, Z1={P3}

-   -   I=Z&Z1=NULL    -   J=Z-Z1={P2}    -   Q=Z1-Z={P3}

Now, sets Z and Z1 are respectively replaced by disjoint sets J and Q.

-   -   X3, J, Q, Z2, Z3

Then, mutually exclusive and collectively exhaustive disjoint sets I1,J1, K1 are determined for sets J and Z2.

J, Z2 J={P2}, Z2={P4}

-   -   I1=J & Z2=NULL    -   J1=J-Z2={P2}    -   Q1=Z2-J={P4}

Now, sets J and Z2 are respectively replaced by disjoint sets J1 and Q1.

-   -   X3, J1, Q, Q1, Z3

Then, mutually exclusive and collectively exhaustive disjoint sets I2,J2, K2 are determined for sets J1 and Z3.

J1, Z3 J1={P2}, Z3={P2, P3, P4}

-   -   I2=J1 & Z3={P2}    -   J2=J1-Z3=NULL    -   Q2=Z3-J1={P3, P4}

Now, sets J1 and Z3 are respectively replaced by disjoint sets I2 andQ2.

-   -   X3, I2, Q, Q1, Q2    -   X3={P1}, I2={P2}, Q={P3}, Q1={P4}, Q2={P3, P4}

Thus, now all of the sets are independent and can be mapped to the hostsbased on the initial assumptions to produce the following desiredprocess clusters:

-   -   P1->H1, H2, H3    -   P2->H1, H2    -   P3->H1, H3    -   P4->H1, H3    -   P3, P4->H1, H3

Based on this output, it can be determined that processes P1, P2, P3 andP4 are separate services. In addition, it can be determined thatprocesses P3 and P4 together constitute a service. In otherimplementations, processes P3 and P4 can be determined to be separateservices. This can be achieved by defining a rule such as “Service_X=P3or Service_Y=P4”, or they can identified by a user as separateprocesses.

Service Profile Classification Workflow

FIG. 4 illustrates a workflow 400 of generating hierarchical serviceoriented application topology for a network. Other implementations mayperform the actions in different orders and/or with different, fewer oradditional actions than the ones illustrated in FIG. 4. Multiple actionscan be combined in some implementations. For convenience, this chart isdescribed with reference to the system that carries out a method. Thesystem is not necessarily part of the chart.

In workflow 400, application data is provided to the feature extractionengine 112 at action 402. The feature extraction engine 112 carries outtokenization of the application data at action 412 and divides eachcommand string into segments, and further divides each of the segmentsof the command string into sliding windows of N grams called tokenshingles.

At action 414, the feature extraction engine 112 filters the tokenshingles by calculating term frequency-inverse document frequency(TF-IDF) for the token shingles. In other implementations, otherfiltering techniques can be used, including but not limited to, log(tf), tf/max (tf), log [tf/max (tf)], entropy, global frequency (GF),and total document IDF weighted global frequency (GFIDF). At action 416,certain junk processes are detected and filtered out based on contentsof the command strings representing the different processes. In oneexample, command strings representing certain processes such as printqueues, fax queues or other administrative processes that are notuser-service oriented (e.g. virtual network computing) are automaticallyconsidered to be junk and deleted.

At action 418, the filtered processes are provided as input for commandparameter(s) based clustering of a plurality of hosts of a network ataction 420. The command parameters comprise command strings representingdifferent processes. A plurality of similarity metrics can be employedto evaluate the command strings and to identify similar processes. Onceidentified, the similar processes are then grouped into clusters, whichspecify hosts that share common functionality.

At action 422, the command parameter(s) based clustering is refinedbased on human feedback. In some implementations, human feedback can bereceived on the clustered hosts and processes. For example, an operatorcan choose to ignore an entire process cluster or reject certainspecific hosts and/or processes from a cluster. Subsequent clusteringoperations can take into account such feedback and produce moreuser-desired results. In other implementations, users can select aprocess cluster or a subset of processes in the process cluster andfurther assign them a service profile from a pre-selected list ofprofiles.

In yet other implementations, the users can specify their own customservice profiles, constituting custom clustering, performed at action424.

At action 426, rule-based classification and/or logistic regression withcross-validation is used to map hosts into service profiles. This actionis referred to as process clustering. In some implementations, theclassification engine 128 classifies the hosts based upon a logisticregression algorithm. Classification engine 128 applies the logisticregression algorithm to the binary command string vectors of theprocesses to compute the probability P of a classification of the hostswhich run those processes.

In some implementations, the rule engine 428 acts as a classificationengine. In such an implementation, the rule engine 428 evaluates theprocesses and the sets of processes against the process-specific andservice specific rules specified in the rules database 108, and furtherclassifies them accordingly.

At action 440, the clustered hosts are classified into service profiles.This action is referred to as service classification. In oneimplementation, the classification is performed using the rule engine428, as described above. In another implementation, the classificationis based on receiving manual labelling of hosts from users, which isused in turn used to train machine learning based classifiers. Forexample, an operator can evaluate the processes running on a host suchas an application server and can use his or her experience to identifythe host as belonging to a particular type of service profile like Mongodatabase service. The labelled service clusters can also be used by therule engine for subsequent classification of the hosts in accordancewith the previously recorded user feedback.

At action 442, unlabeled clusters are presented to the user forfeedback. In one implementation, receiving user feedback at action 448includes deleting certain clusters at action 444. In anotherimplementation, the user feedback includes users specifying customservice profiles at action 446 based on the user's needs and systemarchitectures. In other implementations, user feedback is inducted intothe rules database 108 at action 448 so that it used for subsequentclustering and classification of hosts and processes into serviceprofiles.

Communication Patterns Graphic

FIG. 5 depicts one implementation of a communication patterns graphic500 that graphically represents a host oriented network topology. Inother implementations, communication patterns graphic 500 may not havethe same tabs, widgets, windows, screen objects, elements, or componentsas those listed above and/or may have other/different tabs, widgets,windows, screen objects, elements, or components instead of, or inaddition to, those listed above, such as network topology graph,inter-anomaly time spacing, slider zoom control, or resource redundancygraph. The different tabs, widgets, windows, screen objects, elements,or components can be combined into single software modules and multiplesoftware modules can run on the same hardware.

As illustrated by FIG. 5, host based mapping creates a graphic that isunsuitable for human processing. The overload of information creates aconvoluted graphic that requires substantial human effort and timebefore it can be benefited from. For instance, if an anomaly is detectedin the network, it would take the network operator great time andthinking to determine which hosts or other network entities might beimpacted by the detected anomaly or subsequently might be impacted inthe near future.

In contrast, FIG. 6A shows a communication patterns graphic 600A thatgraphically represents a service oriented application topology. Comparedto graphic 500, the number of graph elements in graphic 600A issignificantly less, making graphic 600A much more operator-friendly.Such a streamlined presentation of network architecture is achieved duethe service oriented approach of graphic 600A. Thus, upon detection of anetwork anomaly, the network operator can use a plurality of elegantanalysis techniques to identify the consequences of the detectedanomaly.

In one example shown in FIG. 6B, the service, which constitutes the hoston which the anomaly occurred, is flagged. In one implementation, theoperator can hover over the flagged service and be presented with adrill-down menu 602 that lists the hosts and/or other network entitiesclustered as the service. Upon drilling-down, the operator can identifythe particular host on which the anomaly occurred based on the flaggingof the host.

In another example, the operator can identify which other hosts and/ornetwork entities are impacted by the detected anomaly by tracking whichservices are connected to the service on whose host the anomaly isdetected. Using the example illustrated in graphic 600B, if the networkanomaly is detected on host “Hadoop1” of service “ZooKeeper-1”, then theimpacted network entities can be identified by tracking the connection604 of service “ZooKeeper-1” that leads to impacted or likely to beimpacted service “HBaseRegionServer-1”. Upon drilling-down 606 theservice “HBaseRegionServer-1”, impacted or likely to be impacted hostsand/or other network entities can identified, such as host“pacific-data1”.

In other implementation, the impacted or likely to be impacted networkentities can be identified using other visual feedback or schemes suchas color coding, filled shapes, blinking or dimming effects, and/orother distinctive background, effects, shapes or markers.

In other implementations, communication patterns graphics 600A and 600Bmay not have the same tabs, widgets, windows, screen objects, elements,or components as those listed above and/or may have other/differenttabs, widgets, windows, screen objects, elements, or components insteadof, or in addition to, those listed above, such as network topologygraph, inter-anomaly time spacing, slider zoom control, or resourceredundancy graph. The different tabs, widgets, windows, screen objects,elements, or components can be combined into single software modules andmultiple software modules can run on the same hardware.

In particular, communication patterns graphics 600A and 600B depict theconnections between services and/or the hosts and the services. In someimplementations, constructing the communication patterns graphics 600Aand 600B include two actions. In the first action, a raw connectiongraph is built between the hosts (e.g. Host A->Host B). This rawconnection graph also specifies various connection statistics such asnumber of connections, average connection lifetime and average datatransfer volume.

In the second action, an aggregated service graph is built. Theaggregated service graph aggregates host-level connections intoservice-level connections (e.g. Service A->Service B, Service A->Host B,Host A->Service B). This aggregated service graph also specifies variousconnection statistics including but not limited to number ofconnections, distinct pairs of hosts, time since last connection andconnection lifetime.

Flowchart of Understanding Traffic Patterns in a Network

FIG. 7 is a flowchart 700 showing a method of understanding trafficpatterns in a network with a multitude of processes running on numeroushosts. Flowchart 700 can be implemented at least partially with adatabase system, e.g., by one or more processors configured to receiveor retrieve information, process the information, store results, andtransmit the results. Other implementations may perform the actions indifferent orders and/or with different, fewer or additional actions thanthose illustrated in FIG. 7. Multiple actions can be combined in someimplementations. For convenience, this flowchart is described withreference to the system that carries out a method. The system is notnecessarily part of the method.

This method and other implementations of the technology disclosed caninclude one or more of the following features and/or features describedin connection with additional methods disclosed. In the interest ofconciseness, the combinations of features disclosed in this applicationare not individually enumerated and are not repeated with each base setof features. The reader will understand how features identified in thissection can readily be combined with sets of base features identified asimplementations such as service oriented application topology generationenvironment, vector space model representation, process similaritydetermination, process and host clustering, host classification, rulebased classification, disjoint process generation, or communicationpatterns graphic.

At action 710, command parameters are derived from application startupdata using a parser that determines which of the command parameters arerelevant for identification of services. The command parameters includeat least one of interpreter, script name, program name, service port andoptions.

At action 720, derived command parameters are used to ignore one or moreprocesses that are not user-service oriented. In one implementation, theclustering further includes determining which groups of processes areco-located on hosts. In another implementation, the clustering furtherincludes receiving human feedback on the clustering and updating thegrouped processes based on the human feedback. Further, a combination ofthe determined co-located groups and the updated grouped processes isused for further clustering.

At action 730, processes running on numerous hosts are clustered intolocal services and the local services running on multiple hosts areclustered into service clusters. Clustering the processes furtherincludes parsing of application startup data for the numerous hosts. Theparsing includes generating tokenized shingles of the applicationstartup data.

At action 740, the service clusters are used to aggregate communicationsamong the local services and the processes running on the hosts. In oneimplementation, common functionality between the numerous hosts isidentified based on similarities between the tokenized shingles.

At action 750, a graphic of communication patterns is generated amongthe service clusters with available drill-down into details ofcommunication links in the communication pattern graphic.

Other implementations can include a non-transitory computer readablestorage medium storing instructions executable by a processor to performany of the methods described above. Yet another implementation caninclude a system including memory and one or more processors operable toexecute instructions, stored in the memory, to perform any of themethods described above.

Computer System

FIG. 8 is a block diagram of an example computer system 800 forunderstanding traffic patterns in a network with a multitude ofprocesses running on numerous hosts. Computer system 810 typicallyincludes at least one processor 814 that communicates with a number ofperipheral devices via bus subsystem 812. These peripheral devices caninclude a storage subsystem 824 including, for example, memory devicesand a file storage subsystem, user interface input devices 822, userinterface output devices 820 and a network interface subsystem 817. Theinput and output devices allow user interaction with computer system810. Network interface subsystem 817 provides an interface to outsidenetworks, including an interface to corresponding interface devices inother computer systems.

User interface input devices 822 can include a keyboard; pointingdevices such as a mouse, trackball, touchpad, or graphics tablet; ascanner; a touch screen incorporated into the display; audio inputdevices such as voice recognition systems and microphones; and othertypes of input devices. In general, use of the term “input device” isintended to include all possible types of devices and ways to inputinformation into computer system 810.

User interface output devices 820 can include a display subsystem, aprinter, a fax machine, or non-visual displays such as audio outputdevices. The display subsystem can include a cathode ray tube (CRT), aflat-panel device such as a liquid crystal display (LCD), a projectiondevice, or some other mechanism for creating a visible image. Thedisplay subsystem can also provide a non-visual display such as audiooutput devices. In general, use of the term “output device” is intendedto include all possible types of devices and ways to output informationfrom computer system 810 to the user or to another machine or computersystem.

Storage subsystem 824 stores programming and data constructs thatprovide the functionality of some or all of the modules and methodsdescribed herein. These software modules are generally executed byprocessor 814 alone or in combination with other processors.

Memory 827 used in the storage subsystem can include a number ofmemories including a main random access memory (RAM) 830 for storage ofinstructions and data during program execution and a read only memory(ROM) 832 in which fixed instructions are stored. A file storagesubsystem 828 can provide persistent storage for program and data files,and can include a hard disk drive, a floppy disk drive along withassociated removable media, a CD-ROM drive, an optical drive, orremovable media cartridges. The modules implementing the functionalityof certain implementations can be stored by file storage subsystem 828in the storage subsystem 824, or in other machines accessible by theprocessor.

Bus subsystem 812 provides a mechanism for letting the variouscomponents and subsystems of computer system 810 communicate with eachother as intended. Although bus subsystem 812 is shown schematically asa single bus, alternative implementations of the bus subsystem can usemultiple busses.

Computer system 810 can be of varying types including a workstation,server, computing cluster, blade server, server farm, or any other dataprocessing system or computing device. Due to the ever-changing natureof computers and networks, the description of computer system 810depicted in FIG. 8 is intended only as one example. Many otherconfigurations of computer system 810 are possible having more or fewercomponents than the computer system depicted in FIG. 8.

The terms and expressions employed herein are used as terms andexpressions of description and not of limitation, and there is nointention, in the use of such terms and expressions, of excluding anyequivalents of the features shown and described or portions thereof. Inaddition, having described certain implementations of the technologydisclosed, it will be apparent to those of ordinary skill in the artthat other implementations incorporating the concepts disclosed hereincan be used without departing from the spirit and scope of thetechnology disclosed. Accordingly, the described implementations are tobe considered in all respects as only illustrative and not restrictive.

What is claimed is:
 1. A system for generating hierarchical serviceoriented application topology of a network with a multitude of processesrunning on numerous hosts, the system comprising: receiving, from anetwork-connected machine learning-based classifier, service profilesclassifying hosts that run similar processes, the machine learning-basedclassifier being trained to cluster the hosts into service profiles by:evaluating command parameters of respective processes running on thehosts by applying logistic regression to string vectors of the commandparameters to calculate a probability of classifying a host into aparticular service profile, and based on the evaluation, classifyinghosts that run similar processes as having a same service profile;receiving, from a network-connected graphic generator, a graphic of thetopography of the network, the graphic generator generating the graphicof the topology of the network based on the service profiles produced bythe machine learning-based classifier; and a user interface outputdevice providing, for display, the graphic generated.
 2. The system ofclaim 1, wherein the service profiles cluster hosts that share commonfunctionality.
 3. The system of claim 1, wherein the machinelearning-based classifier evaluates string vectors of the commandparameters against process-specific rules stored in a rule database. 4.The system of claim 1, wherein the string vectors are chosen based ontheir respective term frequency-inverse document frequencies (TF-IDFs)prior to being evaluated by the machine learning-based classifier. 5.The system of claim 1, wherein the machine learning-based classifierapplies a logistic regression algorithm that uses cross-validation toclassify hosts into service profiles.
 6. The system of claim 1, whereinthe machine learning-based classifier is trained using manually labelledtraining data.
 7. The system of claim 1, wherein the machinelearning-based classifier includes a neural network.
 8. The system ofclaim 1, wherein the machine learning-based classifier applies a naïvebayes algorithm to command parameters.
 9. A method of generatinghierarchical service oriented application topology of a network with amultitude of processes running on numerous hosts, the method including:obtaining service profiles of hosts clustered using a trained machinelearning-based classifier that: evaluates command parameters ofrespective processes running on the hosts by applying logisticregression to string vectors of the command parameters to calculate aprobability of classifying a host into a particular service profile, andbased on the evaluation, classifies hosts that run similar processes ashaving a same service profile; and obtaining a graphic of the topologyof the network generated based on the service profiles produced by thetrained machine learning-based classifier; and providing the graphic ofthe topology of the network as output to a user interface output devicefor presentation.
 10. The method of claim 9, wherein the serviceprofiles cluster hosts that share common functionality.
 11. The methodof claim 9, wherein the trained machine learning-based classifierevaluates string vectors of the command parameters againstprocess-specific rules stored in a rule database.
 12. The method ofclaim 9, wherein the string vectors are chosen based on their respectiveterm frequency-inverse document frequencies (TF-IDFs) prior to beingevaluated by the trained machine learning-based classifier.
 13. Themethod of claim 9, wherein the trained machine learning-based classifierapplies a logistic regression algorithm that uses cross-validation toclassify hosts into service profiles.
 14. The method of claim 9, whereinthe trained machine learning-based classifier is trained using manuallylabelled training data.
 15. The method of claim 9, wherein the trainedmachine learning-based classifier includes a neural network.
 16. Themethod of claim 9, wherein the trained machine learning-based classifierapplies a naïve bayes algorithm to command parameters.
 17. One or morenon-transitory computer readable media having instructions storedthereon for performing a method of generating hierarchical serviceoriented application topology of a network with a multitude of processesrunning on numerous hosts, the method including: obtaining serviceprofiles of hosts clustered using a trained machine learning-basedclassifier to cluster the hosts into service profiles by: evaluatingcommand parameters of respective processes running on the hosts byapplying logistic regression to string vectors of the command parametersto calculate a probability of classifying a host into a particularservice profile, and based on the evaluation, classifying hosts that runsimilar processes as having a same service profile; and obtaining agraphic of the topology of the network generated based on the serviceprofiles produced by the trained machine learning-based classifier. 18.The one or more non-transitory computer readable media of claim 17,wherein the trained machine learning-based classifier includes a neuralnetwork.
 19. The one or more non-transitory computer readable media ofclaim 17, wherein the trained machine learning-based classifierevaluates string vectors of the command parameters againstprocess-specific rules stored in a rule database.
 20. The one or morenon-transitory computer readable media of claim 17, wherein the trainedmachine learning-based classifier applies a logistic regressionalgorithm that uses cross-validation to classify hosts into serviceprofiles.